Fix: Docker connection issue in sandbox by binding to all interfaces#9977
Fix: Docker connection issue in sandbox by binding to all interfaces#9977dtometzki wants to merge 5 commits into
Conversation
Summary of ChangesHello @dtometzki, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a critical connectivity problem in the Docker sandbox environment where the application was inaccessible to external tools like an IDE. By changing the network binding from the loopback address to all available interfaces, the application can now be properly reached, ensuring smoother development and testing workflows within containerized setups. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request correctly changes the server binding to 0.0.0.0 to support Docker environments. However, it introduces a critical security vulnerability by completely removing the Host header check. This exposes an unauthenticated endpoint to the local network, which could allow an attacker to perform actions in the user's IDE. I've suggested a way to mitigate this by re-introducing a more flexible host check.
| @@ -159,18 +159,6 @@ export class IDEServer { | |||
| }), | |||
| ); | |||
|
|
|||
There was a problem hiding this comment.
Removing the host header check introduces a critical security vulnerability. By binding the server to 0.0.0.0, it becomes accessible from the local network. Without the host check, any device on the network can send requests to it. Although most requests require an auth token, initialize requests are unauthenticated for backward compatibility. This could allow an attacker on the same network to trigger actions in the IDE, such as opening a diff view with malicious content (openDiff tool), which poses a security risk.
I suggest re-introducing a host check that is flexible enough for the Docker use case. Checking just the hostname part of the Host header against a list of allowed hostnames like localhost and 127.0.0.1 would be much safer and should still work with Docker port forwarding.
app.use((req, res, next) => {
const hostname = (req.headers.host || '').split(':')[0];
const allowedHostnames = [
'localhost',
'127.0.0.1',
];
if (!allowedHostnames.includes(hostname)) {
return res.status(403).json({ error: 'Invalid Host header' });
}
next();
});There was a problem hiding this comment.
yes it is correct but we are in a conflict here between header sec and sandbox env.
There was a problem hiding this comment.
Hi @chrstnb
who is responsible here ? I dont get any update since weeks
Damian
dtometzki
force-pushed
the
sandbox
branch
7 times, most recently
from
2fed184 to
6332e14
Compare
The application port in the sandbox environment (Docker) couldn't be accessed by the IDE when listening on the loopback address (127.0.0.1). This patch updates the binding address from '127.0.0.1' to '0.0.0.0' to listen on all available network interfaces, ensuring connectivity with external processes like the IDE. Damian
|
Hi, any update ? Damian |
|
We will review this this week. Thank you for your patience. |
|
Hi @cornmander any news to this pull request ? Damian |
|
any update on this. The issue was closed automaticly but wihout any response to this. Damian |
gemini-cli
Bot
added
the
priority/p2
|
Thank you for submission to the Gemini CLI project. At this time, we are closing this pull request in order to allow us to better triage and support more recent pull requests against the latest code changes. If you feel like this pull request is a critical contribution to the Gemini CLI project, please associate the pull request with an existing GitHub issue (instructions here: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue) before reopening. After Monday January 26 2026, any pull requests submitted by contributors without an associated issue will be automatically closed (more information here: #16706). If you do choose to reopen and submit this pull request, please ensure you rebase your changes onto the current main branch before resubmitting. This will help avoid merge conflicts and ensure your contribution is compatible with the latest codebase. |
4 participants
TLDR
The application port in the sandbox environment (Docker) couldn't be accessed by the IDE when listening on the loopback address (127.0.0.1). This patch updates the binding address from '127.0.0.1' to '0.0.0.0' to listen on all available network interfaces, ensuring connectivity with external processes like the IDE.
It doesnt work since git commit d746eb7 feat(vscode-ide-companion): harden ide-server with CORS and host validation (#8512
Damian
Dive Deeper
Reviewer Test Plan
Testing Matrix
Linked issues / bugs